NESTE CAPÍTULO:
Muitas pessoas estão reclamando do Visual Basic .NET. A principal queixa refere-se ao fato de que elas já estavam bem confortáveis com o VB atual. É verdade que ocorreram mudanças dramáticas e que os programadores de VB atuais levaram uns três anos para se sentirem à vontade com a versão 6.0. Contudo, há algumas fortes razões para mudar para o VB .NET, e a curva de aprendizado, embora íngreme no início, pode ser vencida com a compreensão de alguns dos novos conceitos, principalmente o de .NET Framework.
Uma das questões mais comuns hoje em dia é "Porque eu devo migrar para a .NET?". .NET é nova, e há muitas questões sobre o que ela pode fazer por você. De um ponto de vista do Visual Basic, é importante entender alguns dos benefícios dramáticos que podem ser obtidos pela migração para o Visual Basic .NET.
Muitas pessoas têm olhado para o VB .NET e reclamado das mudanças. A ponto de uma publicação comercial ter divulgado um artigo no qual vários programadores experimentados em Visual Basic reclamavam de as mudanças terem sido tantas que eles se sentiam chocados. Afinal de contas, há muitas mudanças na linguagem: um novo tratamento de erros (que é opcional), namespaces, herança real, multithreading real e muitas outras.
Muitos desenvolvedores, porém, sentem que há boas razões para as mudanças no VB .NET. O mundo das aplicações estã mudando, continuando a evolução que tem ocorrido nos últimos anos. Se você voltasse a 1991 e mostrasse para um desenvolvedor de Visual Basic 1.0 um aplicação multicamadas com páginas em ASP no front end, um componente VB COM na camada central com MTS ou COM+, e o SQL Server no back end repleto de stored procedures, isto iria parecer completamente alienígena para ele. Além disto, nos últimos anos, a maioria dos desenvolvedores têm usado o VB para criar componentes COM, e esse têm se tornado bem destros no uso de ADO para fazer acesso a bancos de dados.
A necessidade de reutilização e centralização ( um mode de evitar a distribuição de componentes para as estações de trabalho) têm direcionado este movimento para o modelo multicamadas.
O próximo passo lógico na evolução dos sistemas multicamadas era tornarem-se aplicações para a Web. Infelizmente, o movimento para a Web revelou alguns problemas. Escalabilidade era um deles, mas aplicações mais complexas tinham outros requisitos, tais como transações que envolviam múltiplos componentes, múltiplos bancos de dados, ou ambos. Para responder a estas necessidades, a Microsoft criou o Microsoft Transaction Server (MTS) e o COM+. O MTS (no Windows NT 4) e o COM+ ( uma atualização do MTS no Windows 2000) agem como um ambiente de agrupamento de objetos, permitindo a você ganhar escalabilidade e transações distribuídas com relativa facilidade. Contudo, componentes VB não podem tirar todas as vantagens do Serviço de Componentes tem a oferecer, como pooling de objetos, porque o VB não suporta verdadeira multithreading.
No modelo ASP/VB6, a Microsoft tinha os desenvolvedores criando um componente e o chamando via ASP. A Microsoft reconheceu que seria uma boa idéia tornar este componente diretamente acessível via HTTP, tal que uma aplicação em qualquer parte do mundo poderia usar este componente. Microsoft conseguiu isto atráves do Simple Object Access Protocol (SOAP), que permite aos desenvolvedores chamar um componente via HTTP usando uma string XML. Os dados são então retornados via HTTP em uma string XML. Componentes expostos via SOAP
Componentes expostos via SOAP são acessíveis como qualquer outro item da Web por URLs. SOAP tem a vantagem de ser um padrão global e não apenas da Microsoft. Isto tem feito que um grande número de vendedores, incluindo arqui-rivais da Microsoft, a bradar os benefícios dos serviços Web.
Neste ponto, você pode ser tentado a pensar que o SOAP é tudo que você precisa, e que você pode resolver tudo com o VB 6.0. Portanto, é importante entender o que o VB .NET lhe dá, e porque faz sentido para você e muitos outros desenvolvedores mudar para o .NET. Por exemplo, você cria os componentes e os torna acessíveis via SOAP, mas como você faz as pessoas saberem que eles existem? .NET inclui um mecanismo de descoberta que permite que você encontre componentes que estão disponíveis para você. Você verá mais sobre este mecanismo na aula 9, "Criando Serviços Web com o VB .NET". NET também oferece muitos outros recursos, tais como limpeza de recursos, herança real pela primeira vez, depuração que funciona entre linguagens e com aplicações em execução e a possibilidade de criar serviços para Windows e aplicações tipo console.
Antes de prosseguir, é importante entender um pouco mais sobre o que significa .NET. Há muitos .NETs aqui. Há o VB .NET, que é a nova versão do Visual Basic. Há o Visual Studio .NET (um ambiente integrado que hospeda o VB .NET), o C# (pronunciado "C sharp"), e o C++ .NET. A Microsoft tem chamado muitos dos seus produtos servidores ce ".NET Servers" agora. Subjacente a tudo isto está a .NET Framework e seu dispositivo central de execução, a Common Language Runtime (Linguagem Comum de.Tempo de Execução).
No modelo .NET, você escreve aplicações destinadas à .NET Framework.Isto lhes dá automático acesso a benefícios tais como destruição de objetos e recuperação de memória para você), depuração, serviços de segurança, herança e outras coisas mais. Quando você compila o código de qualquer linguagem que suporta a .NET Framework, ele é compilado em algo chamado de MSIL, ou Microsoft Intermediate Language. Este arquivo MSIL é binário, mas não é linguagem de máquina; pelo contrário, é um formato independente de plataforma e pode ser executado em qualquer máquina que tenha a .NET Framework. Na .NET Framework há um compilador chamado Just-In-Time, ou compilador JIT. Ele compila o código MSIL para o hardware e sistema operacional da máquina.
Olhando para as mudanças fundamentais, é importantde entender que a exigência número um dos programadores em VB, por anos, tem sido herança. VB tem tido herança de interface desde o VB4, mas os desenvolvedores queriam herança real ou herança de implementação. Porque? Quais são os benefícios? O grande benefício da herança é poder criar aplicações mais rapidamente. Esta é uma extensão da promessa de reutilização de código pela orientação a objetos. Com a herança de implementação, você cria uma classe básica e constrói outras classes que herdam dela a implementação. Por exemplo, você pode criar uma classe Veículo que provê a funcionalidade básica que pode ser herdada pela classe Bicicleta e pela classe Carro. O pont importante aqui é que as classes Bicicleta e Carro herdam a funcionalidade, o código real, da classe Veículo. No VB4 e posteriores, o máximo que você podia fazer era herdar a estrutura e nenhum código de implementação. No VB .NET, a funcionalidade da classe base está disponível para as suas outras classes, ou você pode estendê-la e modificá-la conforme seja necessário.
.NET oferece ferramentas de depuração integradas. Se você já depurou uma aplicação em ASP que tinha um componente COM feito no VB, você sabe que tinha que usar o Visual Interdev para depurar o código em ASP e o VB para depurar o código do componente. Se você também tivesse componentes C++ na mistura, teria que usar o depurador C++ naqueles componentes. Com .NET, há um único depurador. Qualquer linguagem da .NET Framework pode ser depurada com este mesmo depurador, mesmo que uma parte da sua aplicação seja escrita em VB .NET e chame outra parte escrita em C#, ou qualquer outra das linguagens destinadas à .NET Framework.
.Net oferece um mecanismo de segurança padrão, disponível para todas as partes da sua aplicação. .NET oferece uma solução possível para o inferno das DLLs, e remove muito da complexidade de lidar com o COM e o registry. .NET permite que você execute componentes localmente, sem exigir que a aplicação chamadorea vá ao registry para encontrar componentes.
Há também coisas que o VB .NET pode fazer que você não pode fazer hoje em VB. Por exemplo, aplicações Web são um novo tipo de projeto. O Visual Interdev está morto com seu código VBScript interpretado . No lugar, você pode agora criar suas páginas ASP.NET com VB .NET (ou C# ou C++ .NET), e elas serão verdadeiramente compiladas para melhor performance. VB .NET deixa você criar serviços Windows nativamente pela primeira vez oferecendo o tipo de projeto Windows Services. E sim, VB .NET permite que desenvolvedores em VB criem verdadeiros componentes e aplicações multithreaded pela primeira vez.
Finalmente, você precisa reconhecer que uma nova linguagem tem que ter um número de versão para ela, enquanto o nome final não tiver sido decidido. Poderia perfeitamente ser chamada de VB .NET 2002. Isto implica que em algum ponto haverá novas versões do VB .NET, como já houveram do VB. Neste curso, referências a versões prévias do VB serão chamadas de VB ou VB6. Referências ao VB .NET 2002 serão apenas VB .NET.
Você decidiu migrar do VB 6.0 para o VB .NET e você iniciou este curso para saber das mudanças. E então, a primeira coisa que você vê é uma dissertação sobre a .NET Framework. Por que iniciar pela .NET Framework? A verdade é que você não pode entender VB .NET sem antes entender a .NET Framework. Você verá que a .NET Famework e o VB .NET são fortemente interligados; muitos dos serviços que você criará dentro das suas aplicações são fornecidos na verdade pela .NET Framework e são meramente chamados em ação pela sua aplicação.
A .NET Framework é uma coleção de serviços e classes. Ela existe como uma camada entre as aplicações que você escreve e o sistema operacional. Este é um conceito poderoso: a .Net Framework não é necessáriamente uma solução para Windows. A .NET Framework poderia ser movida para qualquer sistema operacional, significando que suas aplicações .NET poderiam rodar em qualquer sistema operacional que hospedasse a .NET Framework. Isto significa que você poderia alcançar verdadeira capacidade multi-plataforma simplesmente criando aplicações .NET para os casos em que a .NET Framework estivesse disponível para outras plataformas. Embora esta promessa de capacidade multi-plataforma é um forte argumento de venda da .NET, não há ainda um anúncio oficial de disponibilização da .NET para outros sistemas operacionais.
Em adição, a .NET Framework é excitante porque ela encapsula muito da funcionalidade básica que costumava ter de ser criada em várias linguagens de programação.A .NET Framework tem o código que faz os formulários Windows funcionarem, assim qualquer linguagem pode usar o código embutido para criar e usar formulários padrão do Windows. Em adição, formulários para a Web são parte da .NET Framework, assim qualquer linguagem .NET pode ser usada para criar aplicações para a Web. Adicionalmente, isto significa que vários elementos de programação serão os mesmos entre as linguagens; um tipo Long terá o mesmo tamanho em todas as linguagens .NET. Isto é ainda mais importante quando se trata de strings e matrizes. Você não mais terá que se preocupar em saber se uma string é uma BStr ou uma CStr antes de passá-la a um componente escrito em uma linguagem diferente, o que tem sido uma preocupação comum para os programadores de VB ao chamar APIs escritas em "C".
Um dos principais componentes da .NET Framework é a Common Language Runtime ou CLR. A CLR fornece vários benefícios para o desenvolvedor, tais como tratamento de erros, segurança, depuração e controle de versão, e estes benefícios estão disponíveis em qualquer linguagem criada para a CLR.Isto quer dizer que a CLR pode servir a uma variedade de linguagens, e pode oferecer um conjunto comum de ferramentas para estas linguagens. A Microsoft criou o VB .NET, C++ .NET, e C# como as principais linguagens para a CLR, o que significa que estas três linguagens dão total suporte para a CLR. Em adição, outras empresas têm sinalizado que fornecerão implementações de outras linguagens, tais como Perl, Python, e mesmo COBOL.
Quando um compilador compila para a CLR, o código é dito código gerenciado. Código gerenciado é simplesmente código que tira vantagem dos serviços oferecidos pela CLR. Para que a CLR funcione com o código gerenciado, este código deve conter metadados. Estes metadados são criados durante a compilação por compiladores que visam a CLR. Os metadados são armazenados com o código compilado e contêm informações sobre os tipos, membros e referências no código. Entre outras coisas, a CLR usa os metadados para:
Localizar classes
Carregar classes
Gerar código nativo
Fornecer segurança
Se você pensar sobre isto, as tarefas acima costumam ser feitas pelo COM e o registry. Uma das metas da .NET é permitir que as aplicações sejam distribuídas sem a necessidade de usar o registry. De fato, os componentes .NET podem ser copiados para um diretório e usados, sem a necessidade de um processo de registro. .NET trata de localizar e carregar os objetos do componente, o que substitui o trabalho que costumava ser feito pelo COM.
A CLR também cuida do tempo de vida dos objetos. Assim como COM/COM+ forneciam contagem de referências para objetos, a CLR gerencia referências a objetos e os remove da memória quando todas as referências desaparecem através de um processo chamado garbage collection . Embora garbage collection lhe dê um pouco menos de controle do que aquele que você tinha no VB, você ganha alguns importantes benefícios. Por exemplo, seus erros diminuirão porque o número de objetos que permanecem na memória apenas por estarem envolvidos em referências circulares será reduzido ou completamente eliminado, porque o .NET tem lógica para lidar com objetos que estão presos a referências circulares. Além disto garbage collections acabam sendo muito mais rápidas que o modo antigo de destruição de objetos no VB. Instancias de objeto que você cria e que são gerenciados pelo CLR são chamados dados gerenciados. Você pode interagir tanto com dados gerenciados como com dados não gerenciados na mesma aplicação, embora só os dados gerenciados lhe dão todos os benefícios da CLR.
A CLR também define um sistema de tipos padrão para ser usado por todas as linguagens que suportam a CLR. Isto significa que as linguagens do tipo CLR terão os integers e longs de mesmo tamanho, e elas terão todas o mesmo tipo de string - sem mais preocupações com BStrs e CStrs! Este sistema padrão de tipos abre as portas para uma poderosa interoperabilidade entre linguagens. Por exemplo, você pode passar uma referência de uma classe de um componente para outro, mesmo se estes componentes sejam escritos em linguagens diferentes. Você também pode derivar um classe no C# de uma classe base escrita em VB .NET, ou qualquer outra combinação de linguagens criadas para a CLR. Não esqueça que COM também tem um conjunto de tipos padrão, mas são padrões binários. Isto significa que com COM, você tem interoperabilidade de linguagens em tempo de execução. Com o padrão .NET , você tem interoperabilidade entre linguagens em tempo de design.
Após ter sido compilado, o código gerenciado contém metadados, os quais contêm informação sobre o componente em si, e os componentes usados para criar o código. A CLR pode verificar para se certificar de que os recursos de que você depende estão disponíveis. Os metadados eliminam a necessidade de armazenar informações sobre componentes no registry. Isto significa que, mover um componente de uma máquina para outra não necessita de registro ( a menos que seja um assembly global, o que será descrito na aula 4, "Criando Classes e Assemblies com o VB .NET") e a remoção de componentes é tão simples como excluí-los.
Como você pode ver, a Common Language Runtime fornece um número de benefícios que não só são novos, mas que enriquecem a experiência de criar aplicações. Outros benefícios que você irá ver em maiores detalhes incluem alguns dos novos recursos de orientação a objetos do VB .NET.
Para entender como suas aplicações VB .NET funcionam, e como diferem do código escrito em VB 6.0 para outras aplicações, é importante entender código gerenciado e como ele funciona. Para usar a execução gerenciada e ganhar os benefícios da CLR, você precisa usar uma linguagem que tenha sido criada para o runtime. Felizmente para você, VB .NET está entre estas linguagens. De fato, a Microsoft quis deixar claro que o VB .NET é a principal linguagem da plataforma .NET significando dizer que o Visual Basic não mais poderá ser chamado de uma "linguagem de brinquedo".
O runtime é um ambiente neutro do ponto de vista de linguagem de programação, o que significa que qualquer fabricante pode criar uma linguagem que tira vantagem das características do runtime. Compiladores diferentes podem expor o runtime em diferentes graus para o programador, assim a ferramenta que você usa e a linguagem na qual você codifica podem parecer funcionar algo diferente. A sintaxe de cada linguagem é diferente, naturalmente, mas quando o processo de compilação se inicia, todo o código deve ser compilado em algo compreensível pelo runtime.
Nota
Só porque uma linguagem se direciona para o runtime não significa que esta linguagem não pode adicionar características incompreensíveis por outras linguagens. Para certificar-se de que seus componentes são completamente utilizáveis por componentes escritos em outras linguagens, você precisa usar apenas tipos que são especificados pela Especificação da Common Language. Os elementos da Especificação da Common Languages serão examinados no Apêndice A, "A Especificação da Common Language".
Um dos aspectos mais interessantes da .NET é que quando você compila seu código, você não compila em código nativo. Antes que vocês desenvolvedores em VB entrem em pânico e temam estar retornando aos dias de código interpretado, saibam que o processo de compilação traduz o código em algo chamado Microsoft Intermediate Language, que é chamado de MSIL ou simplesmente IL. O compilador também cria a necessária meta-informação (informação que descreve informação) e a compila no componente. Este código resultante é independente de CPU.
Após a IL e as meta-informações serem gravadas em um arquivo, este arquivo compilado é chamado de PE, que e abrevia "portable executable" ou "physical executable". Porque o PE contém a IL e as meta-informações, ele é auto-descrito, eliminando a necessidade de uma type library ou interfaces especificadas com a Interface Definition Language (IDL). A meta-informação é tão completa que qualquer linguagem .NET pode herdar das classes contidas neste PE. Lembre-se que a .NET é compatível em tempo de design, e isto permite que, enquanto você desenvolve em VB .NET, você possa herdar de classes criadas no C#, e você terá total acesso ao IntelliSense e outros recursos do Visual Studio .NET.
O seu código não permanece em IL por muito tempo, contudo. A IL é independente de plataforma. porque o arquivo PE contendo a IL pode ser distribuído e instalado com a CLR rodando na .NET Framework em qualquer sistema operacional para o qual exista a .NET Framework. Quando você roda a IL, contudo, ela é compilada em código nativo para a plataforma alvo. Portanto, você ainda está executando código nativo; você não está voltando aos tempos de código interpretado. A compilação para código nativo ocorre via uma outra ferramenta da .NET Framework: o compilador Just-In-Time (JIT).
Com o código compilado, ele poderá rodar dentro do Framework e tirar vantagem das características de baixo nível tais como gerenciamento e proteção de memória. O código compilado é nativo para a CPU na qual a .NET Framework esteja rodando, significando que você está seguramente rodando código nativo e não código interpretado. Um compilador JIT será disponibilizado para cada plataforma na qual a .NET Framework rodar, assim você sempre terá código nativo em qualquer plataforma que rode a .NET Framework. Lembre-se que, até a presente data, a única plataforma é o Windows, mas isto pode mudar no futuro.
Nota
Ainda é possível chamar APIs específicas de sistema operacional, o que obviamente irá limitar sua aplicação apenas àquela plataforma. Isto significa que você ainda pode chamar APIs do Windows, mas seu código não será portável em uma máquina com a .NET Framework em um sistema diferente do Windows.
Curiosamente, o compilador JIT não compila a IL toda quando o componente é chamado pela primeira vez. Ao contrário, cada método é compilado somente na primeira vez que é chamado. Isto evita que você compile seções de código que nunca são chamadas. Após o código ter sido compilado, naturalmente, chamadas posteriores usarão a versão compilada do código. Este código nativo compilado irá permanecer na memória. Contudo, a Microsoft criou um compilador Pré-JIT que compila todo o código de uma vez e armazenar a versão compilada em disco. Esta ferramenta é chamada ngen.exe e pode ser usada para pré-compilar toda a IL. Se a CLR não encontra uma versão pré-compilada do código, ela inicia o compilador JIT para fazer a compilação.
Após o código entrar em execução, ele pode tirar todo o proveito da CLR, com benefícios tais como o modelo de proteção, gerenciamento de memória, suporte para depuração, etc. Muitos destes benefícios serão mencionados ao longo do curso;
Uma das novas estruturas que você criará no VB .NET é o "assembly". Um assembly é uma coleção de um ou mais arquivos físicos. Os arquivos são quase sempre de código, tais como as classes que você cria, mas eles também podem ser de imagens, arquivos de recursos, e outros arquivos binários associados ao código. Tais assemblies são conhecidos como estáticos, porque você os cria e armazena em disco. Assemblies dinâmicos são criados em tempo de execução e não costumam ser armazenados em disco (embora possam sê-lo).
Um assembly representa a unidade de distribuição, controle de versão, reuso e segurança. Se isto soa como as DLLs que você tem criado em Visual Basic nos últimos seis anos, é similar. Assim como uma DLL padrão de COM tem uma type library, o assembly tem um manifesto que contem a meta-informação para o assembly, tais como as classes, tipos e referências contidas na IL. O assembly frequentemente contém uma ou mais classes, assim como uma DLL COM. Na .NET, as aplicações são construídas usando assemblies. assemblies não são aplicações no sentido completo.
Talvez o ponto mais importante sobre assemblies é que: Toda aplicação deve ser constituída de um ou mais assembly.
O manifesto é similar em teoria à type library das DLLs COM. O manifesto contém toda a informação sobre os ítens no assembly, incluindo que partes do assembly são expostas ao mundo exterior. O manifesto também lista as dependências do assembly de outros assemblies. Cada assembly tem que ter um manifesto.
O manifesto pode ser parte do arquivo PE, ou ele pode ser um arquivo separado se o seu assembly contiver mais que um arquivo. Embora esta não seja uma lista completa, um manifesto contém:
Em adição, um desenvolvedor pode atribuir atributos customizados para o assembly, tais como um título e uma descrição.
Um dos grandes benefícios propagandeados do COM foi ser um fim para o inferno das DLLs.Se você pensar nos tempos da programação de 16-bits, você lembrará que você tinha que distribuir um número de DLLs com uma aplicação Windows. Parecia que quase todas as aplicações instalavam as mesmas DLLs, tais como Ctrl3d2.dll. Cada aplicação que você instalava poderia ter uma versão ligeiramente diferente da DLL, e você acabava com múltiplas cópias da mesma DLL, mas muitas de diferentes versões. O que era ainda pior, uma versão poderia ser colocada no diretório WIndows\System e travar muitas das suas aplicações existentes.
O COM foi anunciado como a solução para resolver tudo. As aplicações não mais teriam que procurar por DLLs nos seus próprios diretórios , e então procurá-las no diretório Windows. Com o COM, solicitações por componentes seriam enviadas para o registry. Embora pudessem haver múltiplas versões da mesma DLL COM na máquina, haveria apenas uma versão no registry a cada momento. Portanto, todos os clientes usariam a mesma versão. Isto significa, contudo, que cada nova versão de uma DLL teria que garantir compatibilidade com as versões anteriores. Isto conduziu à necessidade de as interfaces serem imutáveis sob o COM; após o componente entrar em produção, a interface era assumida como imutável. Em teoria soa bonito, mas os programadores poderiam (e o fizeram) distribuir componentes que quebrariam a compatibilidade binária; em outras palavras, eles mudaram, adicionaram, ou removeram propriedades e métodos dos seus componentes. Os componentes modificados então travavam as aplicações clientes existentes. Muitos dos desenvolvedores em VB têm lutado com este problema.
A .NET Framework e a CLR tentam direcionar este problema para os assemblies. Mesmo antes da .NET, o Windows 2000 introduziu a capacidade de uma aplicação examinar o seu diretório local, ao invés de ir ao registry. Isto garante que você sempre tem a versão correta da DLL disponível para a sua aplicação.
O runtime vai além e permite que os componentes tenham declaradas suas dependências de certas versões de outros componentes. Em adição, múltiplas versões do mesmo componente podem rodar na memória simultaneamente, o que a Microsoft chama de instanciação lado a lado ou execução lado a lado.
Mesmo que os componentes .NET não tenham que ser registrados, há um processo semelhante se você tiver um assembly que será usado por múltiplas aplicações. A CLR realmente tem dois caches dentro do seu cache de código: o cache de download e o global assembly cache (GAC). Um assembly que será usado por mais do que uma aplicação é armazenado no global assembly cache rodando um instalador que o coloca no GAC. Se um assembly não se encontra no diretório local nem no GAC, você pode ter um endereço para ele no arquivo de configuração. A CLR faz então o download do assembly e o armazena no chache de download e se liga a ele a partir dalí. Este cache de download é somente para assemblies que precisam ser baixados e não será discutido mais neste curso.
O GAC é onde você coloca um componente se você deseja que múltiplas aplicações o utilizem. É muito parecido com o que você tem nos componentes registrados do VB6. Se o componente não é encontrado no mesmo diretório da aplicação, a aplicação procura-o no GAC, do mesmo modo com o COM pesquisa o registro.
Colocar assemblies no GAC tem muitas vantagens.Assemblies no GAC tendem a ter melhores performances porque o runtime os localiza mais rapidamente e a segurança não tem que ser verificada a cada vez que o assembly é carregado. Assemblies somente podem ser adicionados ao GAC ou removidos dele por alguém que tenha privilégios de administrador.
O interessante é que você pode ter diferentes versões do mesmo assembly carregadas no GAC ao mesmo tempo. Note que eu evitei de dizer "registrado no GAC" porque você não está colocando nada no registro. Mesmo se um componente estiver rodando no GAC, você pode adicionar uma outra versão do mesmo componente rodando em paralelo.
Assemblies podem ser postos no GAC somente se eles tiverem um nome compartilhado. Assemblies e o GAC serão discutidos em maiores detalhes no Capítulo 4.
O Common Type System especifica os tipos suportados pela CLR. Os tipos especificados pela CLR incluem:
Classes — As definições do que irá se tornar um objeto; inclui propriedades, métodos e eventos
Interfaces— A definição da funcionalidade que uma classe implementa, mas não contém nenhum código de implementação
Value Tipes— Tipos de dados definidos pelo programador que são passados por valor
Delegates— Semelhantes a ponteiros de funções no C++ , delegates são frequentemente usados por tratamentos de eventos e callbacks
O sistema de tipos estabelece as regras que os compiladores de linguagens devem seguir para produzir código que seja compatível com múltiplas linguagens. Seguindo o sistema de tipos, fabricantes podem produzir código que é garantido para funcionar com código de outras linguagens e outros compiladores, porque todas as linguagens são consistentes no uso de tipos.
Muitos desenvolvedores em Visual Basic são familiarizados com classes. Classes são definições de objetos que serão criados em tempo de execução. As classes definem as propriedades, métodos, campos e eventos dos objetos. Se o termo "campos" lhe causa estranheza, ele simplesmente significa variáveis públicas expostas pela classe; campos são o modo preguiçoso de criar propriedades. Juntos, propriedades, métodos, campos e eventos são genericamente chamados membros da classe.
Se uma classe tem um ou mais métodos que não contêm qualquer implementação, a classe é chamada de classe abstrata. Em VB .NET, você não pode instanciar classes abstratas diretamente; ao invés disto, você deve herdar delas na criação de outras classes. No VB6, era possível criar uma classe que continha apenas definições de métodos e propriedades, mas sem nenhuma implementação. De fato, esta era a forma como você criava interfaces no VB. Se você criasse uma classe somente com definições de métodos e propriedades e sem código de implementação, você poderia usar a palavra Implements para herdar a interface por outra classe. Você realmente podia instanciar a interface no VB6, mas, por não haver nenhum código de implementação, isto era inútil.
No VB .NET, você pode criar uma classe com código de implementação, ao invés de apenas a interface, e então marcar a classe como abstrata. Agora, outras classes podem herdar dela e usar a implementação nela contida ou sobrepor a implementação por outra conforme seja necessário. Estes são conceitos novos para os desenvolvedores em VB. No passado, oVB tinha apenas herança de interfaces, mas o VB .NET tem herança "real", conhecida como herança de implementação.
No VB .NET, interfaces são separadas das classes. No VB6, você criava interfaces criando classes com definições de métodos e propriedades, mas sem nenhum código de implementação nestes métodos e propriedades. Você verá mais sobre interfaces na próxima seção, mas saiba que, embora uma classe VB .NET pode implementar qualquer número de interfaces, ela pode herdar de uma única classe base. Isto será examinado em maiores detalhes ao longo do curso.
Classes têm um número de características possíveis que podem ser atribuídas, e que são armazenadas na meta-informação. Em adição, membros podem ter características. Estas características incluem itens tais como se a classe ou o membro são herdáveis. Isto será discutido em maiores detalhes no Capítulo 4.
Interfaces no VB .NET são como as interfaces em versões anteriores do VB: elas são definições de uma classe sem a verdadeira implementação. Por não haver nenhum código de implementação, você não pode instanciar uma interface, mas precisa implementá-la em uma classe.
Há uma exceção à regra de "sem código de implementação em uma interface": no VB .NET, vocÊ pode definir os chamados membros estáticos. Estes podem ter código de implementação, e você verá mais sobre eles no Capítulo 4.
Nas linguagens .NET, um tipo padrão de variável, como um integer, é nativo à linguagem, e é passado por valor quando usado como argumento. Objetos, por outro lado, são sempre passados por referência.Contudo, um value type é um tipo definido pelo usuário que funciona de modo parecido com um objeto, mas é passado por valor. Na realidade, value types são armazenados como tipos de dados primitivos, mas eles podem conter campos, propriedades, eventos e tanto métodos estáticos como não-estáticos. Value types não provocam a sobrecarga de um objeto que está sendo mantido na memória.
Se isto parece confuso, pense sobre as enumerações. Enumerações são um tipo especial de value type. Uma enumeração tem um nome e um conjunto de campos que definem valores para um tipo de dados primitivo. Enumerações, contudo, não podem ter suas propriedades, eventos e métodos.
Um delegate é um construto que pode ser declarado em um cliente. O delegate realmente aponta para um método em um objeto particular. Qual método ele aponta para e em que objeto pode ser atribuído quando a instância do delegate é criada na sua declaração. Isto permite que você defina chamadas a vários métodos em diferentes objetos baseado na lógica do seu código.
Delegates são mais frequentemente usados para tratar eventos. Usando delegates, você pode passar eventos para um tratamento centralizado de eventos. Delegates não serão examinados em maiores detalhes neste curso.
A .NET Framework fornece um número de elementos que já estão criados e prontos para uso em qualquer linguagem compatível com a Common Language Runtime. Estes elementos incluem itens como tipos de dados primitivos, funções de I/O, acesso a dados, e segurança da .NET Framework.
Talvez uma das maiores mudanças no modo como os programadores irão trabalhar com o VB .NET é a área de namespaces. Namespaces serão cobertos no Capítulo 3. É importante compreender que a .NET Framework fornece um conjunto de classes e membros utilitários organizados dentro de uma hierarquia chamada namespace. Na raiz da hierarquia está o namespace System. Um namespace agrupa classes e membros dentro de nós lógicos. Desta forma, você pode ter a mesmo nome para um método em mais de um namespace. O método Left() poderia portanto existir no namespace System.Windows.Forms e no namespace Microsoft.VisualBasic.
Uma vantagem dos namespaces é que funções similares podem ser agrupadas dentro do mesmo namespace, independentemente do assembly no qual elas estejam fisicamente alocadas. Qualquer linguagem compatível com o runtime pode usar o namespace System. Por exemplo, se você precisasse acessar dados, você não cria uma referência ao componente ADO.NET. Em vez disto, você referencia, ou importa, o namespace System.Data. Frequentemente, você verá a seguinte linha:
Imports System.Data
Contudo, isto não importa todos os métodos e causa um excesso de código. Ao contrário, instrui o compilador para tratar métodos e tipos dentro do namespace como parte do próprio namespace do seu projeto, assim ao invés de ter de escrever:
Você pode simplesmente fazer uma chamada a
SQLClient()
Há muitos outros namespaces System. Namespaces System incluem a funcionalidade para segurança, threading, I/O binário e de texto, e serviços Web. Como usar os vários namespaces System será apresentado ao longo do curso.
Não deixe o termo namespace assustá-lo. É uma das muitas mudanças fundamentais do VB.NET, mas é um serviço fornecido pelo runtime que dá funcionalidade rica e comum a todas as linguagens construídas para o runtime. À medida que você herda dos namespaces fornecidos para você pelo runtime, sua aplicação poderá rodar em qualquer plataforma que suporte .NET. Pode-se dizer que você está trabalhando no aprendizado do ambiente tanto quanto no aprendizado da linguagem. Este é o motivo pelo qual este capítulo é o primeiro no curso.
No VB tradicional, componentes compilados criavam uma type library para definir o que ia dentro do componente, tal como classes, interfaces, propriedades, métodos e eventos. A comunicação ocorria através de uma interface binária no nível do COM. Infelizmente, uma linguagem poderia esperar como parâmetros tipos de dados e estruturas que não estavam disponíveis em outras linguagens, ou que, no mínimo, seriam difíceis de implementar. Por exemplo, componentes desenvolvidos em C++ frequentemente experam ponteiros ou estruturas, e isto pode ser problemático se o programa cliente do componente estiver escrito em Visual Basic. A .NET Framework procura solucionar isto compilando dados adicionais em cada assembly. Estes dados adicionais são chamados meta-informação e permitem que componentes compilados interajam de modo transparente. Junte isto ao fato de haver um sistema de tipos comum tal que todas as linguagens do runtime compartilham os mesmos tipos e você verá que a interoperabilidade entre linguagens evoluiu.
A meta-informação que é armazenada no componente é binária e contém todos os tipos, membros e referências naquele arquivo ou assembly. A meta-informação é compilada no arquivo PE, mas quando o arquivo é usado em tempo de execução, a meta-informação é movida para a memória de tal forma que ela possa ser acessada mais rapidamente.
Uma das coisas mais importantes a ser entendida é que é a meta-informação que permite ao runtime localizar e executar o seu código. A meta-informação é também usada pelo runtime para criar uma versão válida de código nativo queando a MSIL é compilada. O runtime também usa meta-informação para manipular os detalhes massantes de limpeza de memória e segurança.
Quanto se trata dos benefícios da meta-informação para um programador, saiba que há tantos dados na meta-informação que você pode herdar de um PE criadao até mesmo em uma linguagem diferente, porque a meta-informação oferece grande riqueza de detalhes. Isto significa que você está na verdade herdando de um componente compilado, não um arquivo IDL como era requerido anteriormente. De fato, por ser a meta-informação compilada dentro do PE ou assembly, você não mais precisa de arquivos IDL ou type libraries. Toda a informação está agora contida no PE.
Por padrão, a meta-informação contém os seguintes dados:
Identidade do PE ou assembly: nome, versão , cultura, chave pública
Dependências de outros assemblies
Papéis e permissões de segurança
Tipos exportados
Cada tipo tem as seguintes meta-informções:
Nome, visibilidade, classe base, interfaces implementadas
Membro
Em adição, você pode extender a meta-informação usando atributos. Atributos são criados pelo desenvolvedor e permitem que informações adicionais sejam juntadas à meta-informação.
Se você tem criado componentes COM por agum tempo, você sabe que uma das grandes promessas do COM é a independência de linguagem. Se você criasse um componente em C++, você o poderia usar em VB e vice-versa. Contudo, para chegar a este ponto, o seu código tinha que ser compilado para um padrão COM. Muito disto era tranparente para o desenvolvedor VB, mas seu componente tinha que implementar as interfaces IUnknown e IDispatch. Sem estas interfaces, ele não seria um verdadeiro componente COM. Contudo o COM apenas lhe dá interoperabilidade entre linguagens no nível binário. Isto significa que você somente pode tirar vantagem desta interoperabilidade em tempo de execução.
Agora, contudo, a CLR lhe dá muito mais interoperabilidade entre linguagens. Não apenas você pode derivar classes de um PE escrito em na linguagem A e usá-las na linguagem B, mas a depuração funciona entre componentes de múltiplas linguagens. Desta forma, você pode percorrer o código em um PE escrito em C# e saltar para uma classe base escrita em VB.NET. Isto significa que sua interoperabilidade entre linguagens está ocorrendo em tempo de design e de runtime, não só no runtime que lhe é dado pelo COM. Em adição, você pode gerar um erro (agora chamado de uma exceção) em uma linguagem e tê-lo tratado em um componente escrito em outra. Isto é significativo, porque agora os desenvolvedores podem escrever em linguagens com as quais eles se sentem mais confortáveis, e estarem certos de que outros codificando em diferentes linguagens serão capazes de usar seus componentes com facilidade.
Isto tudo soa bem, e você está provavelmente ficando excitado com as possibilidades. Contudo, há uma exigência: para fazer uso desta grande interoperabilidade entre linguagens, você deve usar apenas aqueles tipos de dados e funções comuns a todas as linguagens. Se você está se interrogando sobre como fazer isto, a boa nova é que a Microsoft já pensou neste problema e estabeleceu um padrão chamado a Common Language Specification ou CLS. Se você programar com a CLS, esteja certo de que você terá completa interoperabilidade com outros programando com a CLS, não importa que linguagens estejam sendo usadas. Componentes que expõem somente as características da CLS são chamados componentes CLS-compatíveis.
Para escrever componentes CLS-compatíveis, você deve usar a CLS nestas áreas chaves:
As definições de classes públicas devem conter apenas tipos CLS.
As definições de membros públicos das classes públicas devem ser de tipos CLS.
As definições de membros que são acessíveis a subclasses devem ser de tipos CLS.
Os parâmetros de métodos públicos em classes públicas devem ser de tipos CLS.
Os parâmetros de métodos que são acessíveis a subclasses devem ser de tipos CLS.
Estas regras falam muito sobre definições e parâmetros para classes e métodos públicos. Você é livre para usar tipos não CLS em classes privadas, métodos privados e variáveis locais. Mesmo se você tiver uma classe pública que você quer que seja CLS-compatível, o código de implementação dentro desta classe não tem que ser CLS-compatível; se a definição for compatível, você está seguro.
A CLS ainda está em evolução, mas os alicerces estão bem estabelecidos. Veja o Apêndice A para os fundamentos da CLS.
Se você criar um componente VB hoje, suas chances para implementar segurança são algo limitadas. Você pode usar o NTFS para atribuir permissões ao arquivo em si. Você pode colocar o componente em um serviço de componente MTS ou COM+ e ativar a segurança baseada no objeto. Você pode chamá-lo via DCOM e usar o DCOMCNFG para atribuir permissões. Você pode sempre codificar sua própria segurança.
Um dos principais benefícios do runtime é que uma inteira infraestrutura de segurança lhe vem embutida. Na verdade, dois modelos principais de segurança estão contidos na .NET Framework: segurança de acesso de código e segurança baseada no objeto. Estes tópicos são discutidos em maiores detalhes no Capítulo 12, "Performance e Segurança".
Esta segurança não controla quem acessa o código, mas o que o código em si pode acessar. Isto é importante, porque permite que você crie componentes que podem ser confiáveis em graus variáveis. Se você cria um componente em VB atualmente e quer fazer acesso a banco de dados, você está livre para fazer chamadas a ADO e conectar-se a um banco de dados (claro, se você tiver uma identificação de usuário válida e uma senha). Com o .NET, contudo, você pode especificar com as ferramentas da .NET Framework que ações o seu componente pode e, mais importante, não pode realizar. Isto tem o benefício de impedir que outros usem o código de formas que você não aprova.
Talvez o principal benefício do CAS é que você pode agora confiar em código baixado da Internet. A segurança pode ser configurada tal que se torna impossível para o código executar qualquer ação perniciosa. Isto irá prevenir muitos dos vírus de macro que se espalham via e-mail atualmente
Segurança Baseada no Objeto é o mesmo tipo de segurança que você obtém quando usa os Serviços de Componente MTS ou COM+. Neste tipo de segurança, você cria o que, na documentação do Windows 2000, é chamado de um descritor de segurança. Um descritor de segurança é um conjunto de informações anexadas a um objeto que especifica as permissões de usuários e grupos para acessá-lo. Na .NET, o Framework determina o chamador, chamado de 'principal', e identifica as suas permissões e dos grupos a que pertence. Diferentemente do que ocorre no COM+, contudo, a .NET não pode assumir que o usuário tem uma conta no NT. Portanto, a .NET permite principals genéricos e customizados, bem como principals padrões do Windows. Você pode definir novos descritores de segurança para cada aplicação se você quiser.
Você acabou de ser conduzido em meio a muitas características importantes do .NET de forma muito rápida. Se alguns dos termos lhe pareceram estranhos, não se preocupe. Ao longo deste curso eles serão cobertos com maiores detalhes. Este curso irá cobrir tudo o que você precisa para se iniciar no uso do VB .NET.
Para aqueles questionamentos sobre o valor de migrar para o .NET, é importante entender os benefícios que o .NET lhe traz. Ter um depurador unificado, ganhar verdadeira multitarefa e, finalmente, ter herança de implementação são grandes passos adiante. A runtime também lhe dá uma bela estrutura de segurança, e você não tem mais que se preocupar em registrar componentes. Web Services permitem que você crie facilmente serviços que são utilizáveis através de uma conexão HTTP padrão.
À medida que você trabalha com o VB .NET, entenda que você também está trabalhando intimamente ligado à .NET Framework. É difícil separar os dois, e quanto melhor você compreender o Framework, melhor programador de VB .NET você será.